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TRANSMISSION CONTROL FOR MINIMIZING CONGESTION 
IN DIGITAL COMMUNICATIONS NETWORKS 

Tftnhnical Field 

The invention relates to transmissions in a digital 
5 communications network and, more specifically, to 

transmission control for minimizing network congestion. 

Background of the Invention 

For preventing loss of data due to congestion in 

digital network communications, a protocol known as 
10 Transmission Control Protocol (TCP) has been proposed for 

the Internet; see Information Sciences Institute, 

"Transmission Control Protocol - Request for Comments 

793", September 1981 and W. Stevens, "TCP Slow Start, 

Congestion Avoidance, Fast Retransmit, and Fast Recovery 
15 Algorithms - Request for Comments 2001", January 1997. 

TCP is based on the notion of fair sharing of 

transmission resources among users. 

TCP is reliable, in the sense that the data received 

at a destination are an exact duplicate of the data that 
20 . was sent. Such reliability may be at the expense of 

transmission delays, however. 

For some transmissions, e.g. real-time audio and 

video, reliability is less important, and the primary 

concern is with the data arriving on time. Specifically, 
25 for example, it is more acceptable to lose an occasional 

frame of video than to have the video start and stop 

repeatedly. 

Summary of the Invention 

For congestion control in a digital communications 
3 0 network such as the Internet or corporate "Intranets", and 
especially for real-time transmissions in such networks, 
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a transmission technique is preferred which is not 
perfectly reliable, but which makes it more likely that 
the data arrive on time. The technique uses an estimate 
of the bandwidth which is available in a network, from a 
5 sender to a receiver. The estimate is increased or 
decreased, by the sender, depending on monitoring of 
acknowledgments from the receiver. 

The technique is compatible with TCP, and its use by 
a sender in a connection results in fair sharing of 
10 network resources with all other connections. It can be 
used, e.g., with well-established protocols such as File 
Transfer Protocol (FTP) and Hyper Text Transfer Protocol 
(HTTP) . 

Brief De scription of the Drawing 
15 Fig. 1 is a representation of packet format for a 

preferred embodiment of the invention. 

Fig. 2 is a flow chart for processing at a network 
server, in accordance with a preferred embodiment of the 
invention . 

20 Figs. 3a and 3b are schematics of communications 

systems in accordance with preferred embodiments of the 
invention, with fixed and adaptable bandwidth 
requirements , respectively . 

Fig. 4 is a flow chart for exemplary rate control 
25 processing in a system according to Fig. 3b. 

Fig. 5a is a graphic representation of system 
behavior for an example in a system in accordance with 
Fig. 3a. 

Fig. 5b is a graphic representation of system 
3 0 behavior for an example in a system in accordance with 
Fig. 3b. 



-2- 



BNSDOCID: <WO 9922477A1_I_> 



WO 99/22477 



PCT/US97/19207 



Fig. 6 is a representation of packet format for a 
preferred embodiment of the invention in a wireless or 
hybrid wired-wireless network. 

Detailed Description of Preferred Embodiments 
5 While preferred embodiments are described in the 

following primarily in method terms, the inventive 
technique also includes systems embodiments, e.g. 
involving a programmed processor. A prototype 
implementation uses a Unix Workstation as network server 

10 and a PC as client server, both programmed in C++. Use 

of special -purpose firmware or hardware is not precluded. 

The technique is window-based in the sense that a 
sender maintains a count of the number of outstanding 
packets, i.e., packets which have been sent, but for 

15 which an acknowledgment has not yet been received from 
the receiver. The sender maintains current an upper 
bound on the number of outstanding packets allowed in the 
network, called the "congestion window" (CWND) and 
providing an indication of the available bandwidth from 

2 0 sender to receiver. Congestion is detected when a packet 
is lost in the network. Alternatively, and especially in 
transmissions of variable-length packets, CWND can be 
maintained in units of bytes rather than units of 
packets . 

25 If the number of outstanding packets is less than 

CWND, the sender can continue to send data into the 
network. Otherwise, the sender must stop transmitting 
data until either CWND increases or the number of 
outstanding packets decreases. If acknowledgments are 

30 received, CWND will increase, and the number of 

outstanding packets will decrease. If no acknowledgments 
are returned, packets will timeout and be deemed lost by 
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the protocol, thus decreasing the number of outstanding 
packets . 

Optionally, selective retransmission can be provided 
for. A current estimate is maintained of the round trip 
5 time, i.e. the time elapsed between sending a packet and 
receiving an acknowledgment . The protocol sends the 
estimate to the receiver in each packet header. When the 
receiver determines that a packet has been lost, it then 
determines if there is enough time to receive the 

10 retransmitted packet before it is needed. If so, the 
receiver can request a retransmission; otherwise, no 
request is made. In real-time audio or video, for 
example, if the receiver has 100 milliseconds worth of 
data buffered for playback when detecting loss of a 

15 packet, and if the estimate for the round- trip time is 

less than 100 milliseconds, a request for retransmission 
is likely to result in timely retransmission of the lost 
packet. Thus, a best-effort attempt is made at 
reliability. 

20 As illustrated by Fig. 1, a data packet includes the 

standard User Datagram Protocol (UDP) header, a 2 -byte 
sequence number, a 4-byte time stamp, and a 4-byte round- 
trip time estimate measured in milliseconds. The 
sequence number is for packet reordering at the receiver, 

25 in case packets arrive out of order. The time stamp is 
media dependent and generally provides an indication of 
the presentation time of the packet. 

Fig. 2 illustrates preferred packet processing by a 
server system. There is a main loop which continually 

3 0 checks whether (i) data can be sent out, (ii) an 

acknowledgment has arrived, (iii) a timeout has occurred, 
or (iv) a retransmission was requested. Initially, CWND 
is set to the size of the first packet to be transmitted, 
ensuring that the first packet can be sent out. 
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"Outstanding acknowledgments" (ACK) is set to zero. 
"Timeout" (TO) is set to 3 seconds, for example, 
indicating the amount of time not to be exceeded between 
sending a packet and receiving its acknowledgment. If an 
acknowledgment is not received in time, the packet is 
assumed to be lost. The system starts out in a "Slow- 
Start Phase" indicated by Phase=SS. 

Since CWND is the size of the first packet, ACK=0, 
and there is data available to send (namely the first 
packet) , the first packet is sent into the network. ACK 
is then increased by the size of the packet sent, 
representing the number of bytes currently in the network 
that have not yet been acknowledged. The system then 
checks whether acknowledgments have arrived. If so, 
Outstanding Acknowledgments is decreased by the size of 
the packet to which the acknowledgment refers: ACK = ACK- 
size. The system then calculates the Round Trip Time 
(RTT) , i.e. the difference between when a packet was sent 
and when the acknowledgment was received. RTT is used in 
the calculation of Timeout (TO) . 

The system maintains an estimate of the round trip 
time, RTT avg , by using the measured RTT, RTT if for each 
acknowledgment. Following D. Comer, "Internetworking with 
TCP/IP", 3 rd Edition, Simon & Schuster, 1995, pp. 191-230, 
RTT avg and Timeout (for future use) are calculated as 
follows: 

Diff = RTTi - RTT avg 
RTT avg = RTT avg + Diff/8 
Devi = 0.25-(|Diff| - Dev ± ) 
Timeout = RTT + 0.2 5 + 3-Dev ± 
Now, in Slow Start Phase, CWND is increased by size: 
CWND = CWND + size; 



WO 99/22477 



PCT/US97/19207 



later, in Congestion Avoidance Phase (Phase^SS) , CWND is 
increased by the square of the size divided by the 
current value of CWND: 

CWND = CWND + size 2 /CWND. 
5 Slow Start calls for increasing the value of CWND 

each time an acknowledgment is received. In the case of 
variable length packets, with CWND being the number of 
bytes of outstanding packets, Slow Start calls for 
increasing the value of CWND by the size of the packet to 

10 which the acknowledgment refers. 

After increasing CWND, there follows checking of 
CWND > SSThresh, the Slow Start Threshold. If true, 
Phase = CA, for Congestion Avoidance. 

Then, concerning timeouts, if an acknowledgment is 

15 not received within Timeout (TO) milliseconds after it 
was sent, the packet is determined to be lost in the 
network and the appropriate action is taken. This 
includes (i) setting SSThresh to half of the current 
CWND, (ii) setting CWND to the value of the next packet 

20 to be sent out (i.e. resetting CWND), (iii) setting Phase 
to Slow Start, (iv) decreasing the outstanding 
acknowledgment by the size of the packet which timed out, 
and (v) doubling the Timeout period (TO) . 

Finally, the system checks for receipt of a 

25 retransmission request. If so, it resends the 

appropriate data and resets SSThresh and CWND to half the 
current value of CWND. This is known as Fast Recovery. 
The system then returns to check for further data to 
send, and whether CWND > ACK, 

3 0 As described, the technique does not depend on 

whether the bandwidth requirements of the media can be 
changed or adapted. Fig. 3a shows a system with non- 
adaptable media, such as MPEG. The server reads the 
media from a file or obtains it from a live source and 
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fills a buffer. At the server, the media pump sends the 
data to the client from the buffer, taking into account 
the current value of CWND determined in accordance with 
Fig. 2, and the media pump supplies the size values for 
5 congestion control. In case of significant congestion, 
CWND will be less than ACK, and this will stop the media 
pump from sending further data for a period of time, 
thereby reducing the media pump transmission rate. 

So long as the average available bandwidth of a 

10 connection is greater than or equal to the bandwidth 
requirements of the media, and so long as there is 
sufficient buffering, the media can be played back 
without interruption. With congestion-minimizing 
processing as described above, few packets will be lost, 

15 and can be retransmitted if there is enough time. 

Buffering provides for variation in the available 
bandwidth: the larger the buffer, the more variation can 
be accommodated. But there is an initial start-up delay 
while a client buffer is being filled, so that increased 

2 0 buffering results in a longer start-up delay. 

As to adaptable media, there are several ways of 
changing bandwidth requirements. In the case of MPEG, 
for example, one way involves dropping frames as 
described by Z. Chen et al . , "Real Time Video and Audio in 

2 5 the World Wide Web", World Wide Web Journal, Vol. 1, 

January 1996. The server finds the picture header in the 
MPEG stream and stops sending data until it finds the 
next picture header in the stream. This has the effect 
of dropping one frame from the media stream, and thereby 

30 reducing the bandwidth requirements. As frames are 

interdependent in MPEG, a frame should not be dropped if 
other frames depend on it, i.e. an I -frame cannot be 
dropped if the stream contains P- or B- frames which 
depend on it. 
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For MPEG video, another technique for bandwidth 
reduction is known as Dynamic Rate Shaping (DRS) as 
described by A. Elef theriadis et al . , "Constrained and 
General Dynamic Rate Shaping of Compressed Digital Video", 
5 Proceedings, 2 nd IEEE International Conference on Image 

Processing, Washington, D.C., October 1995, pp. III. 396- 
3 99. This involves identifying, frame by frame, those 
coefficients in the MPEG stream which are least important 
in terms of image quality, and removing them from the 
10 stream. 

Fig. 3b shows an adaptable media system. Again, the 
original media either is stored locally or is supplied by 
a live source. But, in this case the data enters a media 
adaptation module which shapes the media into an estimate 
15 of the available bandwidth. The shaped media enters the 
buffer, which is then read by the media pump. Again, the 
media pump sends out data so as to comply with the CWND. 
At the client, the data is buffered for presentation to 
the user. The client provides feedback information for 

2 0 congestion control. 

The status of the buffer between the media 
adaptation module and the media pump is critical for this 
system. If the buffer is filling, then the media pump is 
sending data out more slowly than the media adaptation 
25 module is filling the buffer. In this case, the system 
should decrease the bandwidth requirements of the media 
so that the buffer does not overflow, by dropping frames 
or assigning a lower rate to DRS. 

Conversely, if the buffer is emptying, the media 

3 0 pump is sending data out faster than the buffer is being 

filled by the media adaptation module. In this case, the 
system should increase the bandwidth requirements of the 
media so that the user gets the best quality possible. 
Since rate control provides information to the media 
35 adaptation module, it is highly dependent on the time of 
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media being adapted. The media pump operates as in the 
non-adaptable case, sending data only when CWND > ACK. 
Based on the occupancy of the buffer, the adaptable media 
module is instructed to change the rate of the media. 
5 For example, for rate control in MPEG video by frame 

dropping, a frame can be dropped when the buffer is more 
than half full; otherwise, the video is passed unaltered 
to the buffer. Other scenarios, using DRS and more 
sophisticated rate control may be implemented. For 

10 example, if the buffer is filling, the transmission rate 
may be reduced in inverse relationship to the rate of 
buffer filling. 

Fig. 4 illustrates an exemplary rate control 
technique based on measurements of buffer occupancy. 

15 Every 5 seconds, an average buffer occupancy is obtained 

for the previous 5 seconds, Occupancy ± . The change in the 
buffer occupancy since the previous 5 -second interval, 
Occupancy^, is determined as Diffi, Start-up is with 
Occupancy 0 = 0. 

2 0 The Centering factor provides a weighting for the 

occupancy to stay close to the desired occupancy at the 
buffer midpoint. The maximum buffer size is 5 seconds 
worth of data and depends on the originally encoded rate 
of the stream. 
25 If Diffi < 0/ 

Centeringi = Occupancyi/Occupancy desired/ 
where Occupancy desired is the buffer occupancy which rate 
control tries to maintain. Otherwise, 

Centeringi = 2 - (Occupancyi/Occupancy desired ) , 

3 0 the goal being to keep the Centering factor between 0 

and 2 . 

Then, Betai is determined as a direct indication of 
how much demand varies in the network, using the 
Coefficient of Variation of the past and current values 
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of the average occupancy. The coefficient of variation 
is defined as 

Variance (samples) /Mean 2 (samples) , 
where the samples are the two values of the average 
5 buffer occupancy. Beta is then multiplied by 10. If 

Beta is less than 0.1, it is assigned the value 0.1, if 
it is greater that 1.0, it is assigned the value 1.0. 

Finally, the new transmission rate is calculated by 
subtracting, from the previous rate, the value 
10 Beta-Centering-Dif f -8, where the factor 8 is due to Diff 
being in bytes and the rate being in bits. These steps 
are repeated every 5 seconds . 

Adaptable media can cope with more drastic 
variations in network resources, as compared with non- 
15 adaptable media. In non-adaptable media, a decrease in 
network resources results in less data reaching the 
receiver than is needed, and the receiver can rely only 
on its initial buffering to continue playback. 

Fig. 5a shows an example of using a non-adaptive 

2 0 media. In this case, the rate of the media is 300 kbps, 

and the final buffering is 5 seconds (1500 kb) . The 
available bandwidth is continually changing. In the 
beginning there is just enough bandwidth for the media 
and no buffering is used. But as soon as the available 

25 bandwidth decreases to 200 kbps, the receiver must begin 
using its buffering. If the bandwidth stays low for an 
extended period of time, the buffer may become completely- 
depleted, at which time the user will experience an 
interruption in playback. This occurs at around 4 0 

30 seconds. The available bandwidth then increases to 350 
kbps, at which time the buffer can accumulate again. 

With adaptable media, the initial buffering has to 
be used only when the bandwidth requirements of the media 
cannot be reduced further. As illustrated by Fig. 5b, 

3 5 for the same rate and initial buffering as in Fig. 5a, 
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the bandwidth requirements of the media can be reduced 
down to a minimum of 150 kbps. When the available 
bandwidth drops to 200 kbps, the media also is reduced to 
this rate, so that no receiver buffering is used to 
5 compensate for the network. However, once the available 
bandwidth decreases to 100 kbps, the media can only be 
reduced to 150 kbps, and so the receiver buffer begins to 
be depleted. This scenario is more robust, as the 
available bandwidth can drop to 150 kbps and receiver 

10 buffering is not used. 

Congestion control in accordance with the invention 
is applicable wherever some degree of loss can be 
tolerated, including most video and audio codecs, with 
adaptable codecs being preferred. Most video codecs can 

15 be adapted by using frame dropping. Even still images 

can be adapted for real-time applications. JPEG and MPEG 
have similarities in the way they are coded, so that a 
■ technique like DRS can be used on JPEG as well. A new 
standard known as Flashpix has the capability to be 

2 0 displayed at different resolutions, and hence different 

bandwidth requirements when sending a picture across the 
Internet . 

While preferred embodiments have been described 
above under the assumption of a wired network, composed 
25 of fiber-optic or coaxial physical cables, techniques of 
the invention can be used to advantage with wireless 
networks as well . As digital communications protocols 
were originally devised with wired networks in mind, most 
congestion-aware protocols, TCP included, assume that a 

3 0 lost packet indicates congestion. This is practicable in 

wired networks, where bit errors are uncommon. Bit 
errors are more common in a wireless environment, 
however, so that a packet is more likely to become "lost" 
due to an error in the packet, regardless of congestion. 
35 But known systems do not include facilities for informing 
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the receiver when a packet has arrived containing an 
error. Internet Protocol (IP) packets are simply dropped 
at the receiver if there is an error in the header. 

Currently, with UDP, the receiver system has the 
5 option of instructing the sender system not to put error 
checking in packets. This is on a system-wide basis, so 
that all UDP packets coming from the sender system will 
not use error checking, which is undesirable when other 
applications expect UDP error checking. 

10 Preferably, in accordance with a preferred 

embodiment of the invention, the receiver can distinguish 
whether a packet is lost due to congestion or error, in 
an application-specific fashion. 

Fig. 6 illustrates a packet constructed from an IP 

15 packet provided with the shaded area by the operating 

system. Error checking will be over the IP header only, 
so that a bit error there still results in the packet 
being dropped without notification. However, without 
error checking over the payload, a bit error in the 

2 0 payload does not result in the packet being dropped. 

In this embodiment of the invention, the sender 
constructs a UDP header inside the payload of the IP 
packet, for the packet to appear as a regular UDP packet 
at the receiver. In the UDP header, the sender sets the 

2 5 Cyclic Redundancy Code (CRC) field to zero, indicating 

that no error checking is used. Accordingly, when the 
receiver reads the packet, the UDP module of the receiver 
system will not do any error checking, leaving it to the 
application to check for errors. 

3 0 So that packets received with errors are not used, 

the sender must insert its own error checking 
functionality into the payload of the UDP packet it 
constructs. In Fig. 6, this is shown as Application 
Defined CRC. If, using Application Defined CRC, the 
35 receiver determines that there is an error, the receiver 
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application drops the packet and sends a request for 
retransmission to the sender— without invoking 
congestion avoidance to reduce the transmission rate at 
the sender. If there is no error, the packet is used by 
5 the receiver application, with regular acknowledgment. 

In this fashion, the likelihood of a packet being 
dropped by the receiver operating system due to packet 
error is minimized, and greater throughput is realized on 
wireless networks without impairing the performance on 

10 wired networks. No changes are required to the operating 
system nor the underlying network link layer, so long as 
the link layer does not perform error checking over the 
entire link layer packet. 

This preferred technique can be used with all 

15 proprietary client -server protocols which are congestion- 
aware. Such protocols must be proprietary because of 
changes to both the client and the server. Accordingly, 
adaptable media applications are preferred. 
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Claims 



1 1. A method for transmitting data from a sender to 

2 a receiver in a digital communications network, 

3 comprising: 

4 maintaining an estimate of bandwidth available 

5 from the sender to the receiver; and 

6 adjusting transmission based on the estimate. 

1 2. The method according to claim 1, wherein 

2 transmission is in real time. 

1 3. The method according to claim 1, wherein 

2 maintaining the estimate of bandwidth comprises 

3 monitoring of packet loss based on acknowledgments from 

4 the receiver. 

5 4. The method according to claim 1, wherein, in 

6 maintaining the estimate of bandwidth, the sender 

7 maintains a count of packets outstanding. 

1 5. The method according to claim 4, wherein, in 

2 maintaining the estimate of bandwidth, the sender 

3 maintains current an upper bound on how many packets are 

4 allowed to be outstanding. 

1 6. The method according to claim 5, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 7. The method according to claim 1, wherein, in 

2 maintaining the estimate of bandwidth, the sender 

3 maintains a count of bytes outstanding. 

1 8. The method according to claim 7, wherein, in 

2 maintaining the estimate of bandwidth, the sender 
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3 maintains current an upper bound on how many bytes are 

4 allowed to be outstanding. 

1 9. The method according to claim 8, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 10. The method according to claim 1, further 

2 comprising retransmitting a packet which has been 

3 determined by the receiver as having been lost in 

4 transmission or received with an error. 

1 11. The method according to claim 1, further 

2 comprising adapting bandwidth required by the data. 

1 12. The method according to claim 1, further 

2 comprising discriminating between packets lost due to 

3 congestion in the network and packets received with at 

4 least one bit error. 

1 13 . A system for transmitting data from a sender to 

2 a receiver in a digital communications network, 

3 compr i s ing : 

4 means for maintaining an estimate of bandwidth 

5 available from the sender to the receiver; and 

6 means for adjusting transmission based on the 

7 estimate. 

1 14. The system according to claim 13, wherein 

2 transmission is in real time. 

1 15. The system according to claim 13, wherein the. 

2 means for maintaining the estimate of bandwidth comprises 

3 means for monitoring of packet loss based on 

4 acknowledgments from the receiver. 
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5 16. The system according to claim 13, wherein the 

6 means for maintaining the estimate of bandwidth comprises 

7 means for maintaining a count of packets outstanding. 

1 17. The system according to claim 16, wherein the 

2 means for maintaining the estimate of bandwidth comprises 

3 means for maintaining current an upper bound on how many 

4 packets are allowed to be outstanding. 

1 18. The system according to claim 17, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 19. The system according to claim 13, wherein the 

2 means for maintaining the estimate of bandwidth comprises 

3 means for maintaining a count of bytes outstanding. 

1 20. The system according to claim 19, wherein the 

2 means for maintaining the estimate of bandwidth comprises 

3 means for maintaining current an upper bound on how many 

4 bytes are allowed to be outstanding. 

1 21. The system according to claim 20, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 22. The system according to claim 13, further 

2 comprising means for retransmitting a packet which has 

3 been determined by the receiver as having been lost in 

4 transmission or received with an error. 

1 23. The system according to claim 13, further 

2 comprising means for adapting bandwidth required by the 

3 data. 

1 24. The system according to claim 13, further 

2 comprising means for discriminating between packets lost 
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3 due to congestion in the network and packets received 

, 4 with at least one bit error. 

1 25. A system for transmitting data from a sender to 

2 a receiver in a digital communications network, 

3 comprising a processor which is instructed for: 

4 maintaining an estimate of bandwidth available 

5 from the sender to the receiver; and 

6 adjusting transmission based on the estimate. 

1 26. The system according to claim 25, wherein 

2 transmission is in real time. 

1 27. The system according to claim 25, wherein 

2 maintaining the estimate of bandwidth comprises 

3 monitoring of packet loss based on acknowledgments from 

4 the receiver. 

5 28. The system according to claim 25, wherein, in 

6 maintaining the estimate of bandwidth, the sender 

7 maintains a count of packets outstanding. 

1 29. The system according to claim 28, wherein, in 

2 maintaining the estimate of bandwidth, the sender 

3 maintains current an upper bound on how many packets are 

4 allowed to be outstanding. 

1 30. The system according to claim 29, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 31. The system according to claim 25, wherein, in 

2 maintaining the estimate of bandwidth, the sender 

3 maintains a count of bytes outstanding. 
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1 32. The system according to claim 31, wherein, in 

2 maintaining the estimate of bandwidth, the sender 

3 maintains current an upper bound on how many bytes are 

4 allowed to be outstanding. 

1 33- The system according to claim 32, wherein the 

2 upper bound is as specified by the TCP congestion window. 

1 34. The system according to claim 25, wherein the 

2 processor is instructed further for retransmitting a 

3 packet which has been determined by the receiver as 

4 having been lost in transmission or received with an 

5 error . 

1 35. The system according to claim 25, wherein the 

2 processor is instructed further for adapting bandwidth 

3 required by the data. 

1 36. The system according to claim 25, wherein the 

2 processor is instructed further for discriminating 

3 between packets lost due to congestion in the network and 

4 packets received with at least one bit error. 
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